1. Field
The present application relates to apparatus and methods for discriminating (e.g., filtering out) late software commands sent to hardware and, more particularly, to discriminating late software commands so as to prevent the late software commands from disrupting hardware circuitry operation.
2. Background
In many applications involving real-time software processing, hardware is responsible for executing certain operations at precise times specified by software, while software is responsible for complex synchronous processing. Synchronization between software and hardware is typically maintained through interrupts, which signal certain events to software. Software then computes and writes values to hardware registers that need to be updated at certain points in time. As the complexity of real-time software increases, however, it becomes more difficult to estimate the time that software will take to respond to real-time events, such as interrupts from hardware. As a result, it is known to add safety margin time (i.e., padding) to a nominal theoretical time that software can respond to real-time events with a given probability. An example of such a situation where adding safety margins is known, is that of a wireless communication device (e.g., a mobile transceiver) having sleep controller hardware that causes portions of the device to be put to sleep intermittently (i.e., temporarily shutting down circuitry within the transceiver) in order to conserve battery energy. Typically, conservative safety margins are factored in the software and hardware designs of such devices, which reduces the probability of late software commands (i.e., commands issued by software that adversely affect operation of the hardware due to their later timing in a sleep cycle, for example) in such devices to an acceptable level. However, the devices use more energy and run out of power quicker as a consequence of adding the safety margins. Moreover, this approach does not completely eliminate the possibility of disruptive late software commands, but merely reduces their probability to a tolerable level.
In certain applications, better performance may be engendered if late software commands are not executed at all because such late commands are disruptive to the hardware operation to a degree that adversely affects system performance. In such situations, it is possible to minimize the time of the software timely response confidence interval at the expense of a higher percentage of late software commands being ignored by hardware, if such commands being ignored prove statistically insignificant. An example of such a situation may be envisioned in the case of the wireless communication device (e.g., a mobile transceiver) having a sleep controller as discussed above. In such a case, the time of a software timely response confidence interval may be minimized in the sleep controller hardware and software in the wireless communication device (e.g., a mobile transceiver). The device would be allowed to stay turned on in the case where software misses the deadline of writing to registers, rather than lose part of the received communication signals if woken up late.